chore(api): merge main and adapt SQS to the service catalog - #1

…o#153)

## Why

The console's picture of what exists was hardcoded and wrong in both
directions. Availability was declared in **three hand-maintained
places** — a 5-clause boolean in `Layout.tsx:69-73`, a spliced card list
in `useCloudConsoleHomeData`, and the API's own descriptors, which the
sidebar never read.

So registering an adapter did **not** light up the nav, and several
schemas promised capabilities their adapters did not have.

Verified against the live stack (`:4566` floci, `:4577` floci-az v0.9.0,
`:4588` floci-gcp).

## What this fixes

| Gap | Before | After |
|---|---|---|
| Nav ignored the server | Hardcoded boolean; GCP Cloud SQL and GKE
showed "Soon" while their endpoints answered 200 | Rendered from `GET
/clouds/:cloud/services` |
| AWS Lambda invoke | `501 operation_not_supported` — despite the UI
shipping `ServerlessInvokePanel`. Azure had invoke; the flagship did not
| Implemented via `InvokeCommand` with `LogType: Tail` |
| AWS Lambda create | Always failed: raw source text sent where a ZIP
archive is required | Packages inline code into a real archive |
| Azure serverless | Advertised `available`; runtime answers 501
NotImplemented | `coming_soon` with that reason, via a new
`descriptorOverride()` hook |
| AWS networking | `create`/`delete` advertised `available` but threw →
502; `get()` always returned `null` so inspect never worked | `partial`
with reasons; `get()` resolves a VPC |
| Schema for unregistered pairs | 200, then the UI rendered a table that
501'd on every call | 404 |
| GCP runtime status | `checkGcpRuntime` ignored the HTTP status, so an
open port read as "reachable" (the runtime 404s on `/`) | Probes a real
GCS contract |
| Cloud status | Inferred solely from the storage adapter | Probes each
runtime directly, plus per-service status |
| Error → HTTP | Substring matching on `err.message`; every AWS SDK
error name fell through to 502 | Typed errors mapped once →
400/403/404/409/429 |
| `metadata.*` columns | Serverless "Runtime" and "Last Updated"
rendered blank on every row, all three clouds | Resolved via a `path`
accessor |
| Unknown service slug | Silently redirected to Storage as though you
had asked for it | Reports what the runtime actually exposes |

## The main change

`SERVICE_CATALOG` is the single place a service is declared.
`CloudServiceType` derives from its keys, availability comes from
adapter registration, and nav metadata (route, iconKey, group, per-cloud
display name) is served to the frontend.

**Adding a service is now a catalog row + an adapter + a registry line —
and zero frontend files.**

## The guard that keeps it honest

`cloudProxy.test.ts` walks the registry and fails the build if a
capability marked `available` has no adapter method, or if anything not
`available` lacks a `reason`. That single test mechanically prevents
four of the gaps above from recurring.

## Verification

`pnpm lint && type-check && test && build` all green — **359 tests**
across 18 files, up from 160.

The decisive check: commenting out `new AwsEksAdapter(...)` against the
running stack flipped `k8s` to `coming_soon` with a reason and made its
schema 404 — **with no frontend edit**.

```bash
# honesty fix, live
curl -s localhost:4501/api/clouds/azure/services | jq '.[]|select(.service=="serverless")'
#   availability: "coming_soon", reason mentions 501
curl -s -o /dev/null -w '%{http_code}\n' localhost:4577/functions   # 501 = ground truth

# every coming_soon explains itself (expect [] for all three clouds)
curl -s localhost:4501/api/clouds/azure/services | jq '[.[]|select(.availability=="coming_soon" and (.reason|not))]'

# per-service status distinguishes "not implemented" from "down"
curl -s 'localhost:4501/api/clouds/azure/status?services=all' | jq '.services[]|{service,runtime,errorCode}'
```

## Notes for review

- Two tests asserted the old buggy behaviour by name ("returns provider
k8s schemas *without registered adapters*") and are inverted to assert
the 404.
- One pre-existing test made a real call to `:4588`, so it only passed
when no floci-gcp container was running. Now hermetic.
- The `legacyAvailability` field on the `secrets` catalog entry is a
deliberate, labelled wart — Secrets Manager still lives outside Cloud
Explorer. Its removal trigger is the `AwsSecretsAdapter`.
- The 0.2.0 changelog claims GCP Cloud Functions invoke support that was
never implemented. Corrected under Unreleased rather than by editing a
released section; the capability is now advertised as `coming_soon`.
- The wire shape `{error, code, message, detail?}` is unchanged, so the
frontend's `HttpError` parsing needed no change.
- `scripts/service-matrix.ts` generates the README coverage table, so it
can no longer drift.

Unrelated observation: Lambda invoke returns a container-init error from
the emulator because `docker-compose.yml` does not mount
`/var/run/docker.sock` for the `floci` service, though the README's
`docker run` example does. Left alone.

…loci-io#152)

…o#171)

## Summary

The Integration workflow asserts the UI with a single un-retried `curl`,
while the Floci runtime gets a 40-attempt poll. The vite dev server's
startup timing shifted slightly with the frontend container's npm to
pnpm switch (floci-io#152), and the first `main` run containing it lost the
race: `curl :4500` hit connection reset (exit 56) before vite was
listening, with the whole rest of the stack green. The identical commit
passed on rerun with no changes (run 30416428298).

This gives the UI assert the same retry shape as the runtime wait: poll
up to 20 times, 3s apart, fail with a clear error after ~60s.

## Type of change

- [ ] Bug fix (`fix:`)
- [ ] New feature (`feat:`)
- [ ] Breaking change
- [x] Documentation / chore (`docs:` / `chore:` / `ci:`)

## Area

- [ ] Frontend (React UI)
- [ ] API (Bun/Hono backend)
- [ ] Cloud Explorer adapter (`packages/api/src/adapter-*`)
- [x] Build / CI / Docker

## Verification

Failure and recovery observed on `main` run 30416428298: first attempt
failed at "Assert the UI is served" with curl exit 56 and every earlier
step green; rerun of the same commit passed. The new loop exits on the
first 200 (no added latency on healthy runs) and preserves the failure
mode with a clearer error annotation.

## Checklist

- [x] PR title follows Conventional Commits
- [x] `pnpm lint`, `pnpm type-check`, `pnpm test`, `pnpm build` pass
locally (workflow-only change; app code untouched)
- [x] No fake/mock data added
- [x] Focused change, no unrelated refactors

Adapts the SQS work to the service catalog introduced in floci-io#153, which landed
after this branch was opened:

- queue becomes a catalog row (group Integration); the hardcoded service
  lists it used to extend are gone from both the API and the frontend
- the sidebar, Console Home and CloudExplorerPage now derive services from
  GET /clouds/:cloud/services, so they need no queue-specific edit
- schema() reads from the adapter, so the queue branch in CloudProxyService
  is no longer needed; the queue mutations now raise NotSupportedError like
  every other unsupported operation
- catalog tests used 'queue' as their example of an unknown slug; they now
  use 'ledger', which stays outside the catalog
- bun.lock regenerated for @aws-sdk/client-sqs